Group specific access rights

Hello,

I have been asked to set up some requirements modules with two different user group roles: one book captain group where the users shall be able to edit all attribute values, create, modify and delete objects, create and delete links, and one "read and comment" group, where the users basically can read everything, but in addition are able to edit a few attributes' values.

The latter requires a difficult combination of RM access to modules, but R access to most attribute values, and RM access to the few attributes under consideration.

This would mean that I have to set all attribute value access rights to specific, and define the specific access rights. Probably the same for attribute definitions. However, the basic idea behind is not to make the module bullet-proof for evil users, but to avoid inadvertent modifications by inattentive users.

Before I go ahead and write DXL to accomplish this, I would like to ask whether somebody has a better idea, e.g. good experiences with e.g. a pre-attribute-sync trigger etc.

Any comments welcome,

regards,

Peter
Peter_Albert - Tue Mar 09 11:05:16 EST 2010

Re: Group specific access rights
kbmurphy - Tue Mar 09 15:47:31 EST 2010

Peter,

I think DXL is the way to go. If you're on DOORS 9, you can use the discussion feature instead of giving access to the module. Another way (and I'm just throwing this out there, not necessarily recommending it) is to make two modules--one for one group, one for the other, and link them up. Then put a "comment" view in the main module based on the links.

Good luck.

Re: Group specific access rights
llandale - Tue Mar 09 15:48:42 EST 2010

Its very annoying that folks with only 'R' access to the module, cannot open that module edit nor shared, even if they have access to stuff in the module. Tried in vain to get around that.

Your description looks like the reasonable course of action.

Yes, I've had good luck with pre-attr-save triggers, and it would be fairly trivial to make one that denies allows access to certain attributes, or when the user had 'create' rights to the module for the other attributes; denying the edit otherwse)


set(trigPreConPass)    
// Update allowed, unless detected as illegal below   Trigger trg = current;     

if (

null trg) halt() AttrDef ad = attrdef(trg); 

if (

null ad)  halt() Object      obj = object(trg); 

if (

null obj) halt()       
// Error? Module  mod = module(obj) string  NameAttr = ad.name   

if (NameAttr is in the specific list of 
'allowed' attributes, hard coded herein) halt()   
// pass 

if (hasPermission(mod, create)) halt    
// user has module 'create' rights, so can change this attr value   

if (isVisible(mod)) warningBox(
"You don't have permission to edit this object-attr value") set(trigPreConFail)

Louie

Re: Group specific access rights
Peter_Albert - Wed Mar 10 02:41:14 EST 2010

llandale - Tue Mar 09 15:48:42 EST 2010
Its very annoying that folks with only 'R' access to the module, cannot open that module edit nor shared, even if they have access to stuff in the module. Tried in vain to get around that.

Your description looks like the reasonable course of action.

Yes, I've had good luck with pre-attr-save triggers, and it would be fairly trivial to make one that denies allows access to certain attributes, or when the user had 'create' rights to the module for the other attributes; denying the edit otherwse)


set(trigPreConPass)    
// Update allowed, unless detected as illegal below   Trigger trg = current;     

if (

null trg) halt() AttrDef ad = attrdef(trg); 

if (

null ad)  halt() Object      obj = object(trg); 

if (

null obj) halt()       
// Error? Module  mod = module(obj) string  NameAttr = ad.name   

if (NameAttr is in the specific list of 
'allowed' attributes, hard coded herein) halt()   
// pass 

if (hasPermission(mod, create)) halt    
// user has module 'create' rights, so can change this attr value   

if (isVisible(mod)) warningBox(
"You don't have permission to edit this object-attr value") set(trigPreConFail)

Louie

Kevin, Louie,

thank you for your comments. Instead of a recommendation for one action out of two, I now end up with three options :-)

No, seriously, the idea of a comments module is something I will consider as well. It is probably the cleanest solution, but would require some DOORS learning from the "commenters". Creating objects and links is not trivial for everybody...

Thanks Louie for the trigger example. I will try this as well.

Regards,

Peter

Re: Group specific access rights
SystemAdmin - Wed Mar 10 09:55:56 EST 2010

Peter_Albert - Wed Mar 10 02:41:14 EST 2010
Kevin, Louie,

thank you for your comments. Instead of a recommendation for one action out of two, I now end up with three options :-)

No, seriously, the idea of a comments module is something I will consider as well. It is probably the cleanest solution, but would require some DOORS learning from the "commenters". Creating objects and links is not trivial for everybody...

Thanks Louie for the trigger example. I will try this as well.

Regards,

Peter

What Kevin probably meant in detail was to create an empty module, copy objects (with the Copy Objects tool) and link them as you copy.

Then you have modules with the same content, the original can be given only read-only access to the commenters, for the copy module they can do whatever they want and write their comments. As you have links between the objects you can see the comments in the original module through a traceability view.

Re: Group specific access rights
Peter_Albert - Wed Mar 10 10:34:01 EST 2010

SystemAdmin - Wed Mar 10 09:55:56 EST 2010
What Kevin probably meant in detail was to create an empty module, copy objects (with the Copy Objects tool) and link them as you copy.

Then you have modules with the same content, the original can be given only read-only access to the commenters, for the copy module they can do whatever they want and write their comments. As you have links between the objects you can see the comments in the original module through a traceability view.

Commenting is expected to happen on the "life" module, i.e. one also has to take into account modifications, creations and deletions in the "original" module, which would have to be reflected automatically in the "comments" module. I would not like have the commenters see copies of the requirements in "their" module, while the original object has potentially been modified or disappeared. Of course, one could have a trace view there with the original requirements text being displayed, but still there is room for confusion :-)

One could still have the comments in the "comments" module, but there they would be the plain "Object Text". New comment == new object plus link.

However, the issue here is not only related to comments, but also to e.g. requirements justification, and this should really be kept together with the requirements in the same module.

So I think my choices are still between access rights and triggers. I will have to set module level access rights in any case, so I will probably just continue down this path to objects and attributes.

Regards,

Peter